[小ネタ]CodeBuildのビルドイメージごとに利用可能なランタイムバージョンが異なりハマった話

ちょっと離席した隙に猫にパソコンを奪われるとモチベーションも同時に無に帰してしまう日々が続いております。

▲ 猫には全く罪は無く、パソコンを奪われる人間が悪いのです

こんにちは。DA事業本部のShirotaです。
今日も平和に自宅で猫と共に仕事をする日々を過ごしております。
そんなある日、CodeBuildを触っていた私の目の前にこんなエラーが飛び込んできました。

突然の本題　〜エラー・原因・対応策〜

エラーと状況確認

AWSコンソールでCodeBuildのビルドプロジェクトを作成しビルドを実行したところ、以下のようなエラーが発生しました。

[Container] 2022/07/14 06:48:41 Phase complete: DOWNLOAD_SOURCE State: FAILED
[Container] 2022/07/14 06:48:41 Phase context status code: YAML_FILE_ERROR Message: Unknown runtime version named '12' of nodejs. This build image has the following versions: 16

どうやらNode.jsのバージョン関連でエラーが発生しているようです。
エラーメッセージを読み、ランタイムバージョンが記載されているbuildspec.ymlとビルドイメージを確認していきます。

　......
phases:
  install:
    runtime-versions:
      python: 3.8
      nodejs: 12
 ......

ビルドイメージは、2022年7月27日現在最新のものである aws/codebuild/amazonlinux2-x86_64-standard:4.0-22.06.30 を利用していました。

原因

エラーメッセージにも記載がある通りですが、私が利用しようとしたビルドイメージでの利用可能なNode.jsのバージョンとbuildspec.ymlで指定していたNode.jsのランタイムバージョンが異なることが原因でした。
私が利用していたビルドイメージで利用可能なNode.jsのバージョンは 16 、buildspec.ymlで指定していたNode.jsのランタイムバージョンは 12 となっていたのです。

対応策

今回は、利用するビルドイメージを aws/codebuild/amazonlinux2-x86_64-standard:4.0 から aws/codebuild/amazonlinux2-x86_64-standard:3.0 に変更してビルドを実行することによって、上記エラーは無事解消しました。

CodeBuildで利用できるビルド環境では、各ビルドイメージごとに利用可能なランタイムバージョンが異なります。
例えば、Node.jsだとランタイムバージョンと利用可能なビルドイメージの対応関係は以下のようになっています。

Node.jsのランタイムバージョン	利用可能なビルドイメージ
8	Amazon Linux 2 AArch64 standard:1.0
10	Amazon Linux 2 x86_64 standard:3.0 Amazon Linux 2 AArch64 standard:1.0 Amazon Linux 2 AArch64 standard:2.0 Ubuntu standard:4.0
12	Amazon Linux 2 x86_64 standard:3.0 Amazon Linux 2 AArch64 standard:1.0 Amazon Linux 2 AArch64 standard:2.0 Ubuntu standard:4.0 Ubuntu standard:5.0
14	Ubuntu standard:5.0
16	Amazon Linux 2 x86_64 standard:4.0 Ubuntu standard:6.0

他の言語の利用可能なランタイムバージョンとビルドイメージの対応表は、以下AWS公式ドキュメントを参照して下さい。

今回お話ししたかった内容は以上になります。
以下は、どうして今回このエラーが発生したのかという状況を整理するために書き下ろした自分用の備忘録となっております。お時間があり気になった方は読んでいって頂けると嬉しいです。

今回のエラーが発生した経緯

とある既存のリポジトリがGitHub上に2つありました。
主にデプロイフロー用のCDKがあるリポジトリをリポジトリA、その他リソース構築用のCDKがあるリポジトリをリポジトリBと呼ぶことにします。

▲ 図にするほどでもないのですがこういった状況でした

今回、私はリポジトリBにあるCodeBuildのbuildspec.ymlを変更するタスクを実行することになりました。
変更したリポジトリBのbuildspec.ymlをテストを実施しようと思ったので、AWSコンソールからビルドプロジェクトを作成・GitHub上にあるリポジトリBをソースに指定してテストを実施しました。
この時点で、私は リポジトリAの存在をきちんと把握していませんでした 。

▲ 記憶の彼方に消えてしまったリポジトリA

このビルドプロジェクトを作成している際に、「buildspec.yml内で利用されている環境変数、いくつかこのリポジトリに存在しないものがあるな？」と思いつつもビルドプロジェクトそのものに環境変数を指定していきました。この時点でリポジトリAの存在を思い出せていれば良かったのですが、私は完全にその存在を忘れ続けていました。サクッとテストを終わらせたい気持ちに駆られ、面倒な環境変数を次から次へと登録し続けました。
そして、ビルド環境を設定する時にもこう考えていました。

「ビルド環境はどうしよう…… 基本、最新のイメージを指定しておけばエラーが起きる可能性も減らせそうだな！ Amazon Linux2の最新イメージを選択しよう」

詰みです。

かくして、私はリポジトリAの存在を思い出すことなく本題のエラーを発生させることとなったのです。

エラーが解消した後、リポジトリAにあったデプロイフローを構築するスタックを作成するファイルを確認したところ以下の記述を見つけました。

 ......
      environment: {
        buildImage: codebuild.LinuxBuildImage.AMAZON_LINUX_2_3,
 ......

ばっちり aws/codebuild/amazonlinux2-x86_64-standard:3.0 を指定していました。

エラーを解決させた今、改めて振り返ってみる

解決してみるとなんとも初歩的なところでやらかしていたというオチだったのですが、エラーが発生した当時は自分の手で用意したリソースが多く（ビルドプロジェクトや環境変数など）原因の可能性になり得る箇所が複数頭の中に浮かんでしまい、すぐに問題解決に至れませんでした。
既存のリポジトリに変更を加える場合は、そのリポジトリに関連リポジトリが存在するかどうか、環境変数などを見て単体で動いているかが微妙なものだと感じた時点で単体でのテストの実施を再考するようにしようと思いました。

いつかまた同じような状況に出会った時に私が踏み留まれるよう、ここに記録しておきます。
もし、同じような状況に出会った他の方が踏み留まるきっかけとなれたら幸いです。